Method and system for enabling emergency sessions to be established in abnormal cases

ABSTRACT

The invention relates to a method and system for connecting a user equipment to a network in abnormal situations normally not allowing the network element to conduct a call. For establishing an emergency session, the network element is adapted to send an indication to the network, the network, when receiving the indication, accepting the call request and establishing the connection for conducting the emergency session. 
     As an alternative, the network, when receiving the indication, may reject the session request whereupon the user equipment initiates an Anonymous Access PDP Activation procedure with the network. To save time, the network, when receiving the indication, may directly return an Anonymous Access PDP Activation Request message to the user equipment for initiating the Anonymous Access PDP Activation procedure. The network, when receiving the session request including the called number, may be adapted to analyze the called number and, when detecting that the called number is an emergency number, to accept the call request and establish the connection for conducting the emergency session.

FIELD AND BACKGROUND OF THE INVENTION

The invention generally relates to the connection of emergency sessionssuch as emergency calls in abnormal cases, and more specifically refersto bearer establishment for emergency sessions in abnormal situations.

Several problems may arise in ensuring a proper establishment ofemergency sessions.

In 3GPP (Third Generation Partnership Program), it has been proposedthat an MS (Mobile Station) with USIM (User Subscription IdentityModule) performs Attach and signalling PDP context activation. When, atsome point, the user of the MS intends to make an emergency session, theMS signals at PDP context activation that the PDP context will be usedfor an emergency session. In detail, an emergency session can beindicated by e.g. using the Source Statistics Descriptor parameter. TheMS is responsible for properly setting the Source Statistics Descriptorparameter so as to indicate that the PDP context will be used for anemergency session.

Emergency sessions and PDP contexts used for them are of highestpriority. The network is adapted to guarantee the establishment of anemergency session if it gets an indication and a confirmationclassifying the session request to be an emergency session request.

The MS may however not always be able to set the Source StatisticsDescriptor parameter. As an example, some MSs are adapted to check andcompare a dialed number with stored emergency numbers and to set theSource Statistics Descriptor parameter representing an emergency sessionwhen detecting an emergency number. When, however, an actually dialedemergency number is not known by the MS, i.e. not configured to the MS,the MS will not set the Source Statistics Descriptor parameter so as torepresent an emergency session.

Even without properly setting the Source Statistics Descriptorparameter, the PDP context activation for an emergency session shouldproceed. Normally, the serving node such as SGSN (Serving GPRS SupportNode) is the first to make the decision whether or not to proceed withthe PDP context activation.

However, in case of prepaid services, e.g. CAMEL based prepaid services,the serving node such as SGSN may communicate with a control means suchas SCP (Service Control Point) at Attach and at PDP context activation.The control means decides about the continuation. If the prepaid accountis empty, the control means normally does not let the user Attach oractivate a PDP context. Such a case may also arise when the money in aprepaid account is divided, e.g., between the PDP contexts of asubscriber. The MS may be able to perform Attach and signalling PDPcontext activation, but there may be no money left in the prepaidaccount when the MS tries to activate a PDP context for an emergencysession. In case of prepaid services, e.g. CAMEL based prepaid services,when establishing a session, another serving node such as CSCF (CallState Control Function) may communicate with a control means such as SCP(Service Control Point). The control means decides about thecontinuation. If the prepaid account is empty, the control meansnormally does not let the user establish the session. This is the IMSpart. CSCF may communicate with SCP.

Further, there may be a case that the network does not let the MS enterthe network. The MS may not be allowed to roam to the network due tosubscription based restrictions, or the subscription information of theMS may be faulty, or the network considers the MS to be misbehaving,e.g., if the subscriber has not paid bills. The network may in suchcases not allow the MS to perform Attach, i.e. may reject the Attachrequest. In case of an emergency session, the network should, however,let the Attach, the signalling PDP context activation and the emergencysession proceed.

SUMMARY OF THE INVENTION

The present invention provides methods and systems for enablingemergency sessions to be established even in cases where a network wouldnormally reject a connection request, e.g. when a prepaid account isempty or the subscription information is faulty or indicates the barringof connection requests.

According to one aspect, the invention provides a method and/or systemfor preventing barring of bearer establishment for an emergency sessionin a wireless communication system in a case where a subscriber isnormally barred from establishing a bearer for a session, the systemincluding at least one user equipment associated with a subscriber and afirst network element authorizing bearer establishment. When anemergency session is to be set up by the user equipment, an indicationis sent from the user equipment to said first network element, theindication indicating that the session to be established is an emergencysession. When receiving said indication in said first network element,said first network element authorizes bearer establishment in responseto said indication.

The user equipment may be commanded by the user of the user equipment toset up an emergency session e.g. in an emergency situation.

If e.g. the Source Statistics Descriptor parameter indicates‘emergency’, the serving element, e.g. SGSN, sends an ‘emergency’indication to the control means, e.g. SCP.

Another serving node such as CSCF (Call State Control Function) may alsoknow, e.g. by analyzing the dialled number, if a session is an emergencysession. In case of detecting an emergency session, the another controlelement sends an ‘emergency’ indication to the SCP. This is especiallyrelevant if the MS can not set the Source Statistics Descriptorparameter and thus the SGSN can not send the ‘emergency’ indication tothe SCP.

When receiving the indication(s), the SCP can let the PDP contextactivation proceed even if e.g. the prepaid account is empty. Withoutthe indication(s), the PDP context activation would not proceed.

As described above, a problem may also appear if an MS requests Attachto the network for making an emergency session, and the network rejectsthis Attach Request, e.g., because the MS is not allowed to roam to thenetwork. To solve this problem, the MS may indicate in the AttachRequest (and/or PDP Context Activation Request) that an emergencysession will follow.

The SGSN preferably checks that the session established after Attach isreally an emergency session. If not, the session and PDP contexts arepreferably forcibly terminated by the network.

Further details, aspects and advantages of the invention will bedescribed below with reference to specific embodiments and the attacheddrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a first embodiment of a method and system in accordancewith the present invention;

FIG. 2 shows a second embodiment of a method and system in accordancewith the present invention;

FIG. 3 illustrates a third embodiment of a method and system inaccordance with the present invention;

FIG. 4 shows a further embodiment of a method and system in accordancewith the present invention;

FIG. 5 shows a further embodiment of a method and system in accordancewith the present invention;

FIG. 6 illustrates another embodiment of a method and system inaccordance with the present invention;

FIG. 7 illustrates a further embodiment of the present invention;

FIG. 8 shows another embodiment of a method and system in accordancewith the present invention; and

FIGS. 9 to 12 illustrate further embodiments of a method and system inaccordance with the present invention.

DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

FIG. 1 shows an embodiment of the invention which includes a sessionoriginating element, i.e. a session initiating element, such as a mobilestation (MS) 1, a serving network element such as a Serving GPRS SupportNode (SGSN) 2, and a further control element such as a Service ControlPoint (SCP) 3. The further network elements necessary for completing anIP multimedia session such as a terminating element, a gateway node ifprovided, a subscriber information register such as a home locationregister (HLR) or home subscriber server (HSS), etc. are known to theskilled man and are therefore neither shown nor described in moredetail.

In all embodiments described above or below, the MS 1 may be equippedwith a USIM (User Services Identity Module).

The embodiment of FIG. 1 relates to a case where the user hasestablished a prepaid account, and the prepaid account managed by theSCP 3 is empty. In spite of this empty prepaid account, the user of theMS 1 intends to establish an emergency session because of an emergencycase.

This and all further embodiments shown in the figures are implemented soas to allow the conduction of an emergency session even in abnormalcases such as “Prepaid Account Empty”.

The embodiment of FIG. 1 relates to a case where the MS 1 is adapted tobe able to inform the serving node SGSN 2 or another network element onan “emergency session”, e.g. by setting an indication, e.g. the SourceStatistics Descriptor parameter so as to indicate the fact that theintended session is an emergency session. In this case, the MS 1 isresponsible for setting the indication, e.g. the Source StatisticsDescriptor parameter.

When the MS 1 is performing a session initiating procedure such as anAttach procedure, for conducting the emergency session, the MS 1preferably indicates in the initiation request to the SGSN 2, i.e. theAttach request, that an emergency session will follow (emergencyindication). The SGSN 2 sends a message to SCP 3 containing theemergency indication. Because of this emergency indication, the SCP 3returns a Continue message to the SGSN 2 for continuing with the Attach.In this manner, the network elements (e.g. the SGSN 2 or the SCP 3) areinformed on the emergency case and can accept the Attach procedure, evenif the prepaid account is empty. The SCP 3 therefore lets the userattach to the network. The SGSN 2 returns an Attach Accept message tothe MS 1 for continuing with the emergency session.

Similar to the embodiment shown in FIG. 1, the embodiment of FIG. 2relates to a case where the MS 1 is adapted to be able to inform theserving node SGSN 2 or another network element on an “emergencysession”, e.g. by setting an indication, e.g. the Source StatisticsDescriptor parameter so as to indicate the fact that the intendedsession is an emergency session. The MS 1 is responsible for setting theindication, e.g. the Source Statistics Descriptor parameter.

When the MS 1 is performing a PDP context activation procedure, e.g. asignalling PDP context activation procedure or a PDP context activationprocedure to carry the media of the emergency session, e.g., voice, forconducting the emergency session, the MS 1 indicates in the PDP ContextActivation Request that an emergency session will follow (emergencyindication). In this manner, the network (e.g. the SGSN 2 or the SCP 3)is informed on the emergency case and can accept the PDP contextactivation procedure. Similar to the case shown in FIG. 1, the SGSN 2communicates with the SCP 3 at PDP context activation by sending anappropriate message indicating “emergency session” (e.g. emergencyindication) from SGSN to SCP 3 after the SGSN 2 having received a PDPcontext activation request including an emergency indication from MS 1.Thereupon, the SCP 3 returns a Continue message to SGSN 2, even if theprepaid account is empty. The SCP 3 therefore lets the user activate aPDP context. The PDP Context Activation Accept message is then sent fromSGSN 2 to MS 1. This process is likewise applicable to CAMEL basedprepaid.

The embodiment shown in FIG. 3 relates to a case where the prepaidaccount provided for the MS 1 is empty and the MS 1 is unable toindicate that the intended call is an emergency session. For instance,the MS 1 may be unable to set the Traffic Characteristics parameter,e.g. in a case in which the MS 1 sets the Traffic Characteristicsparameter based on known emergency number and the dialled emergencynumber is not known by the MS 1, i.e. not configured to the MS 1. Whenthe MS 1 sends an Attach Request or, as shown in FIG. 3, a PDP ContextActivation Request to SGSN 2, the SGSN 2 normally rejects, afterinquiring the SCP 3 and receiving a Reject message, the Attach Requestor (signalling) PDP Context Activation request because the prepaidaccount is empty and it is unknown to the network that the intendedsession is an emergency session.

When receiving the Attach reject message or, as shown in FIG. 3, theactivate PDP context activation reject message, the MS 1 is adapted toinitiate an anonymous access (AA) PDP context activation by sending anAA PDP context activation request to the SGSN 2. Thereupon, the SGSN 2returns an AA PDP Context Activation Accept message to the MS 1, and aconnection procedure is completed so as to allow the MS 1 to make theemergency session to the dialled emergency number.

The SGSN 2 may send a message to SCP 3 informing the latter on theintended emergency session.

FIG. 5 shows a basic structure and method steps for providing a networkfunction of detecting whether or not an intended session, e.g. call, isan emergency session.

When an MS 1 intends to initiate an emergency session and is able toindicate “emergency”, it sends a session initiation request, e.g. anINVITE message of SIP (Session Initiation Protocol) or other type ofconnection request to a Proxy CSCF (P-CSCF) 5 indicating the number tobe called which in the present case is an emergency number. Before thenetwork, i.e. a control element decides on barring the connectionrequest, the network (P-CSCF 5) is adapted to analyse the dialled numberfor detecting whether or not it is an emergency number.

The proxy CSCF (P-CSCF) 5 may perform the analysing step by comparingthe dialled number with a list of known (e.g. stored) emergency numbers.In the present case, the dialled number is an emergency number. TheP-CSCF 5 therefore returns, to S-CSCF 4, an indication indicating thatthe dialled number is an emergency number, i.e. that the session to bemade is an emergency session, e.g. by sending an INVITE messageindicating emergency to the Serving CSCF (S-CSCF) 4, so as to continuewith the emergency session. The S-CSCF 4 sends a message indicatingemergency session to the SCP 3 which responds with a Continue message,and lets the SGSN 2 proceed with a PDP Context Activation procedure tocarry the media of the emergency session. In detail, the MS 1 sends, toSGSN 2, a PDP Context Activation request with emergency indication. TheSGSN 2 transmits a message with emergency indication to SCP 3 whichreturns a Continue message to SGSN 2. The SGSN 2 thereupon returns a PDPContext Activation Accept message to MS 1 so as to proceed with theemergency session.

In the case shown in FIG. 5, the SCP 3 can get the “emergency”indication and confirmation only from S-CSCF 4 as there is an interfacebetween S-CSCF 4 and SCP 3 but no interface between SCP 3 and P-CSCF 5.The P-CSCF 5 analysing the dialled number therefore sends the“emergency” indication to the S-CSCF 4, e.g. in a SIP (SessionInitiation Protocol) message, for instance in the INVITE message. Withthis information, the SCP 3 can inform the SGSN 2 to proceed with PDPcontext activation as generally represented in FIG. 5.

The indications “emergency indication” sent to S-CSCF 4, SCP 3 and SGSN3 and shown in FIG. 5 may be different from network element to networkelement. It is only necessary that the message receiving elementunderstands that the intended session is an emergency session to beconnected through.

The analysing procedure shown in FIG. 5, or more generally, the networkfunction of detecting whether or not an intended session is an emergencysession, can be implemented in all other embodiments shown in the otherdrawings as well.

FIG. 6 shows a basic structure and method steps for providing a networkfunction of detecting whether or not an intended session, e.g. call, isan emergency session. The embodiment shown in FIG. 6 is quite similar tothe one shown in FIG. 5, with the exception that it is also applicableto a case where the MS 1 is unable to indicate that a session to beinitiated is an emergency session.

When an MS 1 intends to initiate an emergency session but is unable toindicate “emergency session”, it sends a session initiation request,e.g. an INVITE message of SIP (Session Initiation Protocol) or othertype of connection request to a Proxy CSCF (P-CSCF) 5 indicating thenumber to be called.

This request does not contain any indication that the session is anemergency session and that the called number is an emergency number.Before the network, i.e. a control element decides on barring theconnection request, the network (P-CSCF 5) is adapted to analyse thedialled number for detecting whether or not it is an emergency number.Similar to the embodiment of FIG. 5, the proxy CSCF (P-CSCF) 5 mayperform the analysing step by comparing the dialled number with a listof known (e.g. stored) emergency numbers. As, in the present case, thedialled number is an emergency number, the P-CSCF 5 returns, to S-CSCF4, an indication indicating that the dialled number is an emergencynumber, i.e. that the session to be made is an emergency session, e.g.by sending an INVITE message indicating emergency to the Serving CSCF(S-CSCF) 4, so as to continue with the emergency session. The S-CSCF 4sends a message indicating emergency session to the SCP 3 which respondswith a Continue message, and lets the proceed with a PDP contextactivation procedure to carry the media of the emergency session. Indetail, the MS 1 sends, to SGSN 2, a PDP Context Activation Request. TheSGSN 2 transmits a message to SCP 3 which returns a Continue message toSGSN 2. The SGSN 2 thereupon returns a PDP Context Activation Acceptmessage to MS 1 so as to proceed with the emergency session.

Similar to the above case shown in FIG. 5, the SCP 3 can get the“emergency” indication only from S-CSCF 4 via the interface betweenS-CSCF 4 and SCP 3. The P-CSCF 5 analysing the dialled number thereforesends the “emergency” indication to the S-CSCF 4, e.g. in a SIP (SessionInitiation Protocol) message, for instance in the INVITE message. Withthis information, the SCP 3 can inform the SGSN 2 to proceed with PDPcontext activation as generally represented in FIG. 6. The “emergencyindication” sent to S-CSCF 4, SCP 3 and SGSN 3 and shown in FIG. 6 maybe different from network element to network element. It is onlynecessary that the message receiving element understands that theintended session is an emergency session to be connected through.

The embodiment shown in FIG. 7 relates to a case where an MS 1 willnormally not be allowed to enter the network and thus will not beallowed to initiate a session. This may happen in cases where thesubscriber information indicates the MS 1 to be e.g. a “misbehaving” MS1 because e.g. the subscriber has not paid bills, or if all roaming isbarred from the subscriber.

The embodiment shown in FIG. 7 represents a case where MS 1 is able toindicate “emergency”, e.g. by appropriately setting the SourceStatistics Descriptor parameter but something is invalid or wrong in thesubscription information. When the MS 1 is performing Attach procedureby sending an Attach request to the SGSN 2 for initiating an emergencysession, the MS 1 is adapted to indicate, in the Attach request, that anemergency session is to be initiated, as shown in FIG. 7. The SGSN 2receiving the request and emergency indication is therefore informed onthe emergency session to be placed by MS 1 so that the network, e.g.SGSN 2, can accept the Attach procedure, even if something is invalid ordefective in the subscription information. The SGSN 2 may optionallysend a message to SCP 3 for informing the latter on the emergencysession to be performed. The SCP 3 may in this case return a message,e.g. Continue message to SGSN 2, for proceeding with the sessionwhereupon the SGSN 2 sends an Attach Accept to the MS 1.

FIG. 8 shows a further embodiment of the invention and relates to a casein which the subscription information of MS 1 is faulty or comprisesinformation requesting suppression of all sessions to be originated fromMS 1. In the case of FIG. 8, MS 1 is unable to include an emergencyindication in the Attach Request sent to SGSN 2. The SGSN 2 thereforeresponds by sending the Attach Reject message rejecting the Attachrequest. Similar to the embodiment of FIG. 3, the embodiment of FIG. 8is adapted to react to the reject message received from SGSN 2 byinitiating anonymous access (AA) PDP context activation by sending theAA PDP context Activation Request message to SGSN 2. The SGSN 2 returnsan AA PDP Context Activation Accept message and performs a usual AAconnection procedure for allowing the emergency session to be performed

FIG. 10 is similar to FIG. 1. The MS 1 performs the Attach procedure andis able to indicate that an emergency session will follow with“emergency indication”. When receiving the Attach Request with“emergency indication”, the SGSN 2 does not communicate with the SCP 3even if the subscriber is a prepaid subscriber. This way, the Attachprocedure proceeds immediately and the SGSN 2 sends the Attach Acceptmessage to the MS 1.

FIG. 11 is similar to FIG. 2. The MS 1 performs PDP context activationprocedure and is able to indicate that an emergency session will follow.The MS 1 adds “emergency indication” to the PDP Context ActivationRequest message. When receiving the PDP Context Activation Requestmessage, the SGSN 2 does not communicate with the SCP 3 even if thesubscriber is a prepaid subscriber. This way, the PDP context activationprocedure proceeds immediately and the SGSN 2 sends the PDP ContextActivation Accept message to the MS 1.

FIG. 12 is similar to FIG. 5. The MS 1 establishes an emergency session.The S-CSCF 4 receiving the INVITE message with “emergency indication”does not communicate with the SCP 3 even if the subscriber is a prepaidsubscriber. The MS 1 performs the PDP context activation procedure tocarry the media of the emergency session. The MS is able to indicatethat an emergency session will follow. The SGSN 2 receiving the PDPContext Activation Request with “emergency indication” does notcommunicate with the SCP 3 even if the subscriber is a prepaidsubscriber. This way, the emergency session and the PDP contextactivation proceed immediately.

In all above-described embodiments, the emergency session detection bythe network, e.g. implemented by analysing the dialled number (number ofthe terminating equipment) as shown in FIGS. 5, 6, can additionally oralternatively be implemented. When the control means e.g. SCP 3, hasreceived the emergency session indication from the analyzing means, e.g.from P-CSCF 5 via S-CSCF 4 after number analysis, the control means,e.g. SCP 3 can let the attach or PDP context activation or sessionestablishment proceed.

The teaching according to the invention may be employed in networks ofvarious types, i.e. in IMS, GPRS and UMTS domains.

Although the invention has been described above with reference tospecific embodiments, the scope of protection of the invention intendsto cover all modifications, omissions, additions and amendments of thedisclosed features as well.

1. A method, comprising: preventing barring of bearer establishment foran emergency session in a wireless communication system; receiving, whenan emergency session is to be set up for a user equipment, an attachrequest or packet data protocol context activation request from the userequipment, the attach request or packet data protocol context activationrequest including an indication indicating that the session to beestablished is an emergency session; receiving said indication in afirst network element, said first network element authorizing, or beingcontrolled to authorize, bearer establishment in response to saidindication; establishing a session after receiving attach request orpacket data protocol context activation request comprising theindication indicating that the session to be established is an emergencysession; checking that the established session established after theattach request or packet data protocol context activation request, isindeed an emergency session; and when the checking indicates that thesession established after the attach request or packet data protocolcontext activation request is no emergency session, forcibly terminatingthe established session.
 2. Method according to claim 1, wherein thebarring is due to defective subscriber information.
 3. Method accordingto claim 1, wherein the subscriber has a prepaid account for prepaidbilling, and the barring is due to the prepaid account being empty. 4.Method according to claim 1, wherein the barring is due to roaming ofthe subscriber.
 5. Method according to claim 1, wherein the firstnetwork element is a serving network element.
 6. Method according toclaim 5, wherein the serving network element is a serving general packetradio service support node.
 7. Method according to claim 1, wherein theindication is sent in the attach request or a packet data protocolcontext activation request.
 8. Method according to claim 1, wherein thefirst network element forwards said indication to a second networkelement, the second network element checking the indication and decidingon authorizing the first network element to establish a bearerconnection with the user equipment.
 9. Method according to claim 8,wherein said second network element detects the balance of a prepaidaccount provided for the user equipment and regardless of the balanceauthorizes the bearer establishment procedure.
 10. Method according toclaim 1, wherein said indication is the called address.
 11. Methodaccording to claim 10, further comprising extracting the indication fromthe called address.
 12. Method according to claim 1, wherein, when theuser equipment is already attached to a network, the network receives anactivate packet data protocol context activation request from the userequipment which request includes the indication.
 13. Method according toclaim 1, wherein the attach request or packet data protocol contextactivation request is sent to a all state control function, whichanalyzes the indication for detecting whether or not it is an emergencynumber.
 14. Method according to claim 13, wherein the call state controlfunction, is a proxy call state control function, which sends a messageincluding an emergency indication to a serving call state controlfunction.
 15. Method according to claim 14, wherein the serving callstate control function sends a message comprising an emergencyindication to a network element which informs the first network elementto continue with the session.
 16. System, comprising: first networkelement authorizing bearer establishment, wherein the system isconfigured to receive, when an emergency session is to be set up for auser equipment associated with a subscriber, an attach request or racketdata protocol context activation request from the user equipment, theattach request or packet data protocol context activation requestincluding an indication indicating that the session to be established isan emergency session; the first network element being configured, toreceive said indication and to authorize bearer establishment inresponse to said indication, wherein the system is configured toestablish a session after receiving the attach request or packet dataprotocol context activation request including the indication indicatingthat the session to be established is an emergency session, check thatthe established session, established after the attach request or racketdata protocol context activation request, is indeed an emergencysession, and forcibly terminate the established session when the checkindicates that the session established after the attach request orpacket data protocol context activation request is no emergency session.17. System according to claim 16, wherein the barring is due todefective subscriber information.
 18. System according to claim 16,wherein the subscriber has a prepaid account for prepaid billing, andthe barring is due to the prepaid account being empty.
 19. Systemaccording to claim 16, wherein the barring is due to roaming of thesubscriber.
 20. System according to claim 16, wherein the first networkelement is a serving network element.
 21. System according to claim 20,wherein the serving network element is a serving general packet radioservice support node.
 22. System according to claim 16, wherein theindication is comprised in the attach request or packet data protocolcontext activation request or a packet data protocol context activationrequest.
 23. System according to claim 16, wherein said first networkelement is configured to forward said indication to a second networkelement, and the second network element is configured to check theindication and to decide on authorizing the first network element toestablish a bearer connection with the user equipment.
 24. Systemaccording to claim 23, wherein said second network element is configuredto detect the balance of a prepaid account provided for the userequipment and to authorize, regardless of the balance, the bearerestablishment procedure.
 25. System according to claim 16, wherein saidindication is the called address.
 26. System according to claim 25,wherein the system is configured to extract the indication from thecalled address.
 27. System according to claim 16, wherein, when the userequipment is already attached to a network, the network is configured toreceive an activate packet data protocol context request from the userequipment which request comprises the indication.
 28. System accordingto claim 16, wherein the system is configured to send the attach requestor racket data protocol context activation request to a call statecontrol function, which is configured to analyze the indication fordetecting whether or not it is an emergency number.
 29. System accordingto claim 28, wherein the call state control function is a proxy callstate control function, which is configured to send a message includingan emergency indication to a serving call state control function. 30.System according to claim 29, wherein the serving call state controlfunction is configured to send a message comprising an emergencyindication to a network element which informs the first network elementto continue with the session.
 31. An apparatus, comprising: a receiverconfigured to receive an attach request or packet data protocol contextactivation request from a user equipment, the attach request or packetdata protocol context activation request including an indicationindicating that the session to be established is an emergency session; aprocessor configured to authorize, or to be controlled to authorize,bearer establishment in response to said indication, wherein theprocessor is configured to establish a session after receiving theattach request or packet data protocol context activation requestincluding the indication indicating that the session to be establishedis an emergency session, check that the established session, establishedafter the attach request or packet data protocol context activationrequest, is indeed an emergency session, and forcibly terminate theestablished session when the check indicates that the sessionestablished after the attach request or packet data protocol contextactivation request is no emergency session.
 32. An apparatus,comprising: preventing means for preventing barring of bearerestablishment for an emergency session in a wireless communicationsystem, the apparatus comprising a first network element configured toauthorize, or to be controlled to authorize bearer establishment;receiving means for receiving, when an emergency session is to be set upfor a user equipment associated with a subscriber, an attach request orpacket data protocol context activation request from the user equipment,the attach request or packet data protocol context activation requestincluding an indication indicating that the session to be established isan emergency session; receiving means for receiving said indication insaid first network element, said first network element authorizing, orbeing controlled to authorize, bearer establishment in response to saidindication; establishing means for establishing a session afterreceiving the attach request or packet data protocol context activationrequest including the indication indicating that the session to beestablished is an emergency session; checking means for checking thatthe established session established after the attach request or packetdata protocol context activation request, is indeed an emergencysession; and terminating means for forcibly terminating, when thechecking indicates that the session established after the attach requestor packet data protocol context activation request is no emergencysession, the established session.
 33. Apparatus according to claim 31,wherein the barring is due to defective subscriber information. 34.Apparatus according to claim 31, wherein the subscriber has a prepaidaccount for prepaid billing, and the barring is due to the prepaidaccount being empty.
 35. Apparatus according to claim 31, wherein thebarring is due to roaming of the subscriber.
 36. Apparatus according toclaim 31, wherein the first network element is a serving networkelement.
 37. Apparatus according to claim 36, wherein the servingnetwork element is a serving general packet radio service support node.38. Apparatus according to claim 31, configured to send the indicationin the attach request or a packet data protocol context activationrequest.
 39. Apparatus according to claim 31, wherein the first networkelement is configured to forwards said indication to a second networkelement, the second network element being configured to check theindication and decide on authorizing the first network element toestablish a bearer connection with the user equipment.
 40. Apparatusaccording to claim 39, wherein said second network element is configuredto detect the balance of a prepaid account provided for the userequipment and regardless of the balance to authorize the bearerestablishment procedure.
 41. Apparatus according to claim 31, whereinsaid indication is the called address.
 42. Apparatus according to claim41, further being configured to extract the indication from the calledaddress.
 43. Apparatus according to claim 31, being configured toreceive, when the user equipment is already attached to a network, anactivate packet data protocol context activation request from the userequipment which request includes the indication.
 44. Apparatus accordingto claim 31, being configured to send the attach request or packet dataprotocol context activation request to a call state control function,which is configured to analyze the indication for detecting whether ornot it is an emergency number.
 45. Apparatus according to claim 44,wherein the call state control function, is a proxy call state controlfunction, which is configured to send a message including an emergencyindication to a serving call state control function.
 46. Apparatusaccording to claim 45, wherein the serving call state control functionis configured to send a message comprising an emergency indication to anetwork element which is configured to inform the first network elementto continue with the session.